3章 2回測って、1度で切る：上流工程の必要性

導入

家を建てるにあたり、建設業者は設計図を見直し、必要な許可が下りていることを確認し、基礎工事がきちんとできているかどうかを確認する。超高層ビルを建設するときと、一般住宅を建設するときと、犬小屋を建てるときとでは、建てる側の準備の仕方はそれぞれ異なる。

2回測って、1度で切るについて

大工の場合はやり直しが効かないが、ソフトフェアの場合はやり直しがきくため、デスマーチややっつけのコードになりやすい。

3.1 準備の必要性

高品質なソフトフェアは、高品質なプラクティスを取り入れていて、そのためにはプロジェクトのどこかで品質管理のための作業を取り入れている(not テスト)。

品質管理は作るものが正しいか、作り方は正しいかといったことも検証する必要があるがそれはテストでは検知できない。

ロールスロイスが欲しいのなら、最初からそのための計画を立てなければならない。

アーキテクチャ、設計、プロジェクト計画といった上流工程のアクティビティは、現代のソフトウェアプロジェクトには役立たないという意見がある。

コンストラクションの準備作業の最大の目標は、リスクを減らすこと

なぜ準備不足がおきるのか

上流工程の担当者が担当する領域の専門知識を持っていないことによる

プロマネ的なものか、開発するシステムの領域的なものか？

開発するサービス領域の話かも(業界動向とか)

最近だと素早くリリースして動向を見るとか

解決するには章末の参考資料を見てほしい

早くコーディングをしたい病

次の節を読めばOK

これまで経験した問題に着目して、事前計画があれば解決できたことはないだろうか？

準備に時間をかけることに対してあまり評価されない風潮がある

対策1：はっきりと断る

対策2：コードを書いてるふりをする

対策3：準備の重要性を説明する(当然これが建設的)

対策4：転職する

3.2 ソフトフェアの種類の特定

table:システムの種類 と一般的なプラクティス

システムの種類 業務システム(Business Systems) 基幹システム(Mission-Critical Systems) 組み込み医療システム

例 インターネットサイト 組み込みソフトウェア 航空電子工学ソフトウェア

インフラネットサイト パッケージソフトウェア 組み込みソフトウェア

在庫管理 ソフトウェアツール 医療装置

ゲーム Webサービス オペレーティングシステム

システムの分類の仕方が謎だが、自分たちは業務システムまたは、基幹システムにの部類に入るのではないか？

反復型手法には準備がいらないという風潮があるが、そのようなことはない(表3-3, 3-4)

table:反復型と逐次型の違い

反復型 逐次型

仕様が十分に理解されていない。または、変わる可能性がある。 仕様がかなり安定している

設計が複雑である、手間がかかる。 設計がシンプル

開発チームがアプリの分野に詳しくない? 開発チームがアプリの分野に詳しい

プロジェクトのリスクが高い プロジェクトのリスクが低い

長期的な予測が重要である 長期的な予測が重要でない

仕様や設計、コードを変更してもコストが低い 仕様や設計、コードを変更するとコストが高く付く

一部納得できる部分もあれば、よくわからないところもある(逐次型の開発に関わったことある人HELP)

3.3 準備：課題定義

解決するべき問題はなにか？

それはプログラムである必要はない

プログラムを組むより人の手でやったほうが早いこともある

3.4 準備：要求

俗に言う「仕様」のこと

要求を明確にしないと、ユーザーは製品に対して同意できず、プログラマはスコープを引けずにプログラミングできない

コードのエラーはすぐに修正できるが、要求のエラーは設計のフェーズからやり直さないといけない場合がある。その場合は、すでに作成したコードやテストは無駄になる。

table:コスト感

設計時 3倍

コーディング時 5〜10倍

テスト時 10倍

リリース後 10〜100倍

仕様はプロジェクトが進行するにつれて変わっていく。なぜなら、プロジェクトが進行するにつれて、理解度が高まっていくため。

だいたい開発時に作った仕様の25％は変わり、修正には全体の75〜85%を占める

仕様が変わった時には…？

みんなの話を聞きたい

本誌付属のチェックリストにのっとり、仕様が正しいかどうか判断する

仕様変更に伴うコストを関係者に周知する

変更する手順を決める

変更に対応する開発手法を使う

プロジェクトを中止する

プロジェクトの本質を忘れない

3.5 準備：アーキテクチャ

プログラムの構成

クラス設計

データ設計

業務ルール

UI設計

リソース管理

セキュリティ

パフォーマンス

スケーラビリティ

国際化と地域化

入出力

エラー

フォールトトレランス(耐障害性)

アーキテクチャの実現可能性

オーバーエンジニアリング

購入か構築か

再利用

変更方針

優れたアーキテクチャの仕様には、候補も含めてなぜ採用したのか、なぜ採用しなかったのかを明記されている。「いつもそうしているから」は禁句。

アーキテクチャにはリスクも記載し、リスクの原因と対策もまとめる

アーキテクチャには不安要素を残さない

3.6 上流工程にかける時間

上流工程には工数の10〜20％、スケジュールの20〜30％を確保する

仕様が確定していない場合は、とにかく仕様の確定に時間を割く必要がある

未知の分野のときには、多めにバッファを取る

3.7 参考資料

3.8 まとめ

コンストラクションの準備の最大の目的は、リスクを削減すること

高品質なソフトフェアを開発するには、どのフローでも品質に気を配らなければならず、早めに品質に気を配ることで全体の品質向上につながる

プログラマの仕事の1つは、プログラミング前の準備の大切さを説くこと

課題定義が十分でないと、誤った課題を解決することになる

仕様の策定が十分でないと、仕様の変更があったときに20〜100倍のコストがかかるため、プログラミングの前に仕様の検証が必要

アーキテクチャの設計が十分でないと、課題解決の方法が間違ったことになる。アーキテクチャの変更もプログラミングに影響を及ぼすので、アーキテクチャがただしいかどうかも検証するべき

解くべき問題を正しく見極めて、正しい回答方法を考案しなければ高品質なソフトフェアは生み出せない